home *** CD-ROM | disk | FTP | other *** search
/ Amiga Developer CD 2.1 / Amiga Developer CD v2.1.iso / DevInfo / DeviceDevelopment / NSD-Future < prev    next >
Encoding:
Text File  |  1996-10-05  |  2.3 KB  |  52 lines
  1.  
  2.     $Id: NSD-Future 1.2 1996/10/06 09:01:17 heinz Exp $
  3.  
  4.  
  5. Future Directions
  6. =================
  7.  
  8. What are the future directions for NSD? Currently the items
  9. mentioned in the following paragraphs are under consideration. They
  10. are phrased as suggestions to think about. Obviously, thoughtful
  11. comments are very welcome.
  12.  
  13. It may be useful to add NSDEVTYPE_NARRATOR for the future to bring
  14. back a narrator eventually. A future narrator may be a completely
  15. different beast for input and output than the one that used to be
  16. part of the OS, which means that the meaning of a device type like
  17. this needs a lot more thought in general. So if someone has an
  18. intention to create a narrator like NSD device, please get in
  19. contact with us.
  20.  
  21. It has been suggested that the query result should contain the size
  22. of the expected I/O request for general use. This would make it
  23. possible to extend the functionality of an existing device type by
  24. optionally extending its IORequest in agreed upon and standardized
  25. ways without having to introduce a new type specifier. This is
  26. tricky, though, as a single device type may have multiple valid
  27. sizes depending on the command used, like the original
  28. trackdisk.device. Maybe the maximum supported size should be set
  29. here to give an indication of the maximum available request feature
  30. size. Maybe a table of possible sizes, indicating different
  31. features should be returned.
  32.  
  33. SANA devices pass in necessary configuration data on OpenDevice().
  34. This is not really such a great idea within the NSD context.
  35. A general NSD command to pass in configuration data for any device
  36. type may be a very good and very important thing to keep
  37. OpenDevice() close to its original meaning as hinted at in the RKM.
  38.  
  39. There should be comments on how I/O requests are correctly
  40. duplicated. Official documentation on this has always been sketchy
  41. at best, and the fact that for any device type basically only the
  42. io_Device and io_Unit IORequest need to be duplicated, except for
  43. device specific data in an extended request structure, has not been
  44. really defined well.
  45.  
  46. This document needs to be presented in a more readable form and
  47. possibly in hypertext form. It should also continue to be available
  48. in plain text, though. texinfo may be a good and portable choice with
  49. minimum environment needs, as long as illustrations are not needed.
  50.  
  51. *** EOT ***
  52.